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REMARKS/ARGUMENTS 

Prior to this Amendment, claims 1, 3-7, 9-13. 15-18, and 21-35 were pending 
in the application. No claim amendments are presented with this Amendment, and 
the listing of claims js provided for the convenience of the Examiner. 

In the Office Action of August 19, 2005, the Examiner withdrew prior 
rejections of the claims that were based on the combined teaching of U.S. Pat. No. 
6.163,781 ("Wess") and U.S. PaL No. 6,363,388 ("Sprenger"). However, the two 
pending independent claims and a number of the dependent claims are rejected in 
the Office Action by the Examiner who replaced Sprenger's teaching with that of 
U.S. Pat. Appl. Publ. No. US 2002/0133510 ("Lau"). The remaining claims are 
rejected under the combined teachings of Wess, Lau, and Sprenger. 

Claim Rejections under 35 U-S.C, S103 

In the August 1 9, 2005 Office Action, claims 1 , 3, 4, 7, 1 1 , 21 , 28, and 30-35 
were rejected under 35 U.S.C. §103(a) as being unpatentable over Wess in view of 
Lau. The rejection of the claims is traversed based on the following remarks. 

As noted in para. [0003] of the application and the prior Amendment, the 
invention is addressing the problems associated with prior E-commerce systems in 
which a database loader was used to load information but only in tiie forni of tables. 
With reference to para. [0036], the invention uses an import/export utility, that 
knows nothing of the E-commerce system, to deliver infomnation from an external 
data file to a business object that does the "real work" such as perfomning tasks 
including adding, deleting^ or updating the data (see, claim 35) , The changes in the 
data can be performed without requiring the business object to be changed. As 
shown in Fig. 1, the import/export utility communicates with the business object and 
gathers the imported file and provides a database that is used during the 
processing of the import file data by the business object. In this manner, the 
business object is able to import/export data, such as with relation to an E- 
commerce system, without use of a standard database loader and, hence, to load 
data not in the form of a table. 
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With this background in mind, claim 1 is directed to a method of processing 
data with a utility, and the method includes selecting a file that includes a name of a 
business object, uploading the file to a server, storing file data in a database of the 
utility, delivering the data to the business object, and performing a task on the data 
with the business object The combination of Wess and Lau fail to teach or suggest 
all of these elements. Hence, the rejection of claim 1 is improper and should be 
withdrawn. 

More specifically, the Office Action cites Wess at col. 6, lines 1 1-14, col. 6, 
lines 16-29 and 53-57, and col. 13, lines 3-10 for teaching selecting a file that 
includes a name of a business object. Applicants disagree with this construction of 
Wess. Wess at col. 2, lines 30-40 makes it clear that its method is addressing 
problems associated with having a database with many null data values, and 
beginning at line 6, coL 4, Wess provides a brief summary of its method that uses a 
table of defined variable symbols and comparing operations to try to reduce the 
amount of null data values in its relational databases. Hence, Wess is addressing 
a different problem than Applicants and uses a different technique to address that 
problem. 

In the cited col. 6, lines 16-29, Wess is describing the converting data 
received at a network interface 1 12 including "textually-based data objects" into 
formats expected by the system, but at this citation and elsewhere, Wess fails to 
teach selecting a file that has a business object name in the file. This named object 
is then used to perform processing on the data of the file, and Wess fails to suggest 
that its "data objects" are business objects as defined by Applicants. For at least 
this reason, claim 1 is allowable over Wess. The Office Action does not address 
Applicants' arguments, which were provided in the Amendment filed with the RCE. 

Further, the August 19, 2005 Office Action indicates that Wess fails to teach 
"starting a session, a business object, delivering the data to the business object 
corresponding to the name uploaded to the server, with the business object, 
performing a task on the delivered data, the task performing including invoking a 
code included in the business object.'' Due to these deficiencies in Wess, the 
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Office Action then cites Lau for teaching each of these limitations of claim 1 that are 
not found in Wess. Specifically, the following discussion stresses how Lau fails to 
teach or suggest the data delivering step and the perfonming a task on the delivered 
data with the business object step. Hence, In addition to Wess failing to show the 
file selecting step as discussed above, Lau fails to overcome the other deficiencies 
of Wess. 

Initially, Applicants would like to point out that the specific citations or 
references provided in para. 6 of the Office Action to Lau appear to be incorrect or 
to a reference other than Lau. The citations appear to be to an Issued patent (Le., 
with column numbers and line numbers) rather than to the cited Lau publication 
(i.e., with paragraph numt>ers and the like). The parent Lau patent (Ser, No- 
6,381,600) and tfie patent issued based on the published Lau application were both 
reviewed, but the citations provided by the Examiner, such as ''update objects 240" 
and col. 14, were not present in these patents. The Examiner's citations were also 
not found in the Lindsay patent (Ser. No. 6,754,670), which was listed as a cited 
reference in the Ofnce Action. As a result, Applicants reviewed Lau as cited by the 
Examiner and provide the following remarks based on this patent application 
publication - even though the Examiner's specific citations appear to be incon^ct 
(or possibly to another reference not cited in the Office Action). 

Lau in para. [0005] Indicates that it Is trying to solve the problem of 
"^nslation of data from an object-relational database hierarchy to a standard flat 
file data exchange file format for transfer to a second object-relational database. 
To this end. Figure 1 shows an export mechanism 14 (or export transformation step 
as discussed In para. [0028]) and an import mechanism 22 (or import 
transfomiation step as discussed in para. [0028]) in source and target database 
management systems 10, 18. respectively, that function to pass data in the transfer 
file 16. Para. [0030] makes it clear that Lau Is teaching a method for which a 
source DBMS 10 and a target DBMS 18 ''are able to transfer data using the format 
of data transfer file 16." The tree diagram shown in Figure 2 illustrates "an example 
hierarchy of types which define tables in an objectHrelational database." and per 
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para. [0042], "Data transfer file 16 of the preferred embodiment is capable of 
representing the data of the data hierarchy defined by the user in source DBMS 
10." 

From this brief overview of Lau, it can be seen that Lau is solving a very 
different problem than the method of daim 1 . Further, it can l:>e seen that Lau 
provides no teaching whatsoever of "delivering the data to the business object 
corresponding to the name uploaded to the server** There is no discussion of 
business objects in Lau, and clearly, there is no teaching of "with the business 
object performing a task on the delivered data" or further, that "the task performing 
including invoking a code included in the business object ." Para. [0060] provides a 
further description of the method of Lau, and in this description, Lau does not 
describe invoking a code in a business object to perform a task on data delivered to 
that business object. For these reasons, Lau does not overcome the deficiencies 
of Wess, and the combined teaching of Wess and Lau does not support an 
obviousness rejec^on of claim 1. 

Claims 3, 4. 7, 1 1 , 21 , 28, 30-32, 34, and 35 depend from claim 1 and are 
believed allowable as depending from an altowable base claim. Further, claim 34 
calls for the business object to perform validation after receiving the data, and this 
limitation is not shown or suggested by the cited references. In the prior Office 
Action in rejecting claim 14, the Examiner admitted that Wess fails to teach the 
business object being responsible for validating the data in the selected file but 
cites Sprenger at col. 14, lines 59-65 as providing this teaching. In this Office 
Action, however, the Examiner changes the construction of Wess and cites col. 8, 
lines 46-60 of Wess for teaching ttie validation with the business object, but at this 
citation, Wess discusses use of a comparator comparing value attributes but as 
noted above this comparator is not provided in a business object to which data is 
delivered. Hence, Wess fails to tea<^i the validation with the business object. 
Claim 35 calls for the task to be adding, deleting, or updating the delivered data, 
and such tasks are not shown by Lau, which as discussed above fails to teach 
delivering data to a business object and, therefore, cannot teach performing these 
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specific tasks with such a business object by invoking code in the business object,. 
For these additional reasons, claims 34 and 35 are not shown or suggested by 
Wess and Lau, 

Independent claim 33 is directed to a method of loading information to a 
network application and includes steps of operating a utility to invoke a business 
object associated with a business object name from an import file. In the method of 
claim 33. the business object perfomns an operation on data delivered by the utility 
and the method further includes updating the data in a utility database based on the 
performance of the operation of the invoked business object. The operating of the 
utility to invoke the business object and the updating of the data steps are similar to 
limitations presented in claim 1 , and the reasons for allowing claim 1 over the 
combined teaching of Wess and Lau are believed applicable to claim 33. 

More specifically, Wess fails to teach receiving a selection of an import file 
that includes a name of a business object. This named business object is then 
used to perfonm processing on the data of the file, and Wess fails to suggest that its 
"data objects'' are business objects as defined by Applicants and the Examiner's 
prior Response to Argument confimied that Wess only teaches data objects (see, 
fourth paragraph of Response to Arguments). For at least this reason, claim 33 Is 
allowable over Wess. Further, as discussed with reference to claim 1 , Lau does not 
overcome the deficiencies of Wess, and particularly, provides no teaching of the 
uploading, operating, and updating steps of claim 33 that involve the business 
object. Hence, Wess and Lau do not support a rejection of independent claim 33. 

Additionally, in the Office Action, claims 5, 6, 9, 10, 12. 13, 15-18, 22-27. and 
29 were rejected under 35 U.S.C. §1 03(a) as being unpatentable over Wess in view 
of Lau further in view of Sprenger. This rejection Is traversed based on the 
following remarks* 

Claims 5, 6, 9, 10, 12, 13, 15-18, 22-27, and 29 depend from claim 1 and are 
believed allowable over Wess and Lau for the reasons provided above for claim 1 . 
Sprenger does not overcome the deficiencies in Wess and Lau discussed with 
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reference to claim 1, and hence» these claims are believed allowable as depending 
from an allowable base claim. 

As discussed in the previousiy-fiied Amendment, Sprenger in its Summary 
and elsewhere makes It clear that its method is a data management method that 
uses agents and minions (see. Sprenger at coL 8, line 60 and on for a discussion of 
agents and minions) to perform various data management processes, but nowhere 
in Sprenger is it taught to perfonm an operation with a business object named in an 
import ftle on data uploaded to a database by a utilrty. At the cited portions of 
Sprenger. the use of objects Is described but there is no teaching of a utility 
uploading a file and then updating the data based on the performance of the 
operation by the Invoked business object. 

For example. Sprenger at col. 5, lines 1-15 teaches that objects can be 
instantiated from an access layer by accessing the database and later saved to the 
database. Sprenger does not teach invoking a business object based on an import 
file and then, using the invoked business object to perform an operation on data in 
a utility database. For this reason, the pending claims are believed allowable over 
the combination of Wess and Lau in further view of Sprenger. 

Further. Sprenger at col. 14. lines 59-65 discusses operation of an 
"EventLogMinion" but this element does not perform validation of data and does not 
teach that the business object is named in the file providing the data. With this in 
mind. Sprenger also falls to teach the limitations of claim 1 including delivering the 
data to the business object and then performing a task on the data with the 
business object that changes the data. 

Specifically. Wess fails to teach the use of business objects and at col. 14, 
lines 59-65, Sprenger states a minion "provides a central point of access tor all 
advisory messages that need to be stored persistently in the database. The 
'•events" in the log are descriptions of some event in time, such as the observed 
failure of a critical component, or the failure of a job stream to complete. The 
events stored in the log describe unusual conditions that require the attention of the 
user..." Applicants could find no suggestion in Sprenger of either delivering data 
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from to the business object or tiiat a task that changes the data is performed on the 
data by the business object. For these additional reasons, daim 1 is allowable over 
the combined teaching of Wess. Uu, and Sprenger. 

Conclusions 

In view of all of the above, the claims are believed to be allowable, and it Is 
requested that a timely Notice of Allowance be issued in this case. 

No fee is believed due with this submittal. However, any additional fees 
associated with this submittal may be charged to Deposit Account No. 50-1 123. 



Respectfully submitted, 



September 19. 2005 




Hogan & Hartson llp 
One Tabor Center 



1200 17th Street. Suite 1500 
Denver, Colorado 80202 
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(720)406-5301 Fax 
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